CICS is a transaction processing system designed for both online and batch activity. On large IBM zSeries and System z9 servers, for example, CICS easily supports thousands of transactions per second, making it a mainstay of enterprise computing. For this reason, CICS is used in bank teller applications, airline reservation systems, ATM systems, etc.
However, an application program designed to execute in the CICS Transaction Server environment can only access storage within its local CICS region. For example, with distributed processing, many remotely connected CICS regions can distribute databases and workload for load balancing to make the most efficient use of processing capacity. This causes customer information to be distributed, which requires complex coding techniques. This also can make application support and problem determination difficult and time consuming, which can have a negative affect on customer satisfaction and application availability.
CICS applications can be written in numerous programming languages, including COBOL, PL/I, C, C++, IBM Basic Assembly Language, REXX, and Java. But, programming techniques to provide access to storage on a remote CICS region can be complicated and require multiple programs. The CICS Transaction Server for z/OS and V2R3 CICS Application Programming Reference (SC34-6232) describes the available commands to access resources controlled by CICS, and the CICS Transaction Server for z/OS CICS Intercommunication Guide (SC34-6243) describes methods of CICS-to-CICS communication.
By way of example, the programming options available to the CICS applications include:                1. Intersystem Communication (ISC): ISC uses Advanced Program to Program Communication (APPC) which requires a client and server program relationship on both ends of the connection. APPC is a detailed protocol with distinct functions for each end of the conversation and requires careful coding of data syncpointing and error condition processing.        2. CICS Function Shipping: CICS Function Shipping provides access to resources and Virtual Storage Access Method (VSAM) files on a remote CICS region as if they were locally defined. The CICS Function Shipping does not provide a method to access storage (memory) or DB2 databases within the remote CICS region.        3. Asynchronous Processing: Asynchronous Processing allows a local CICS program to initiate a transaction on a remote CICS region and pass data to it, but no reply is possible.        4. Transaction Routing: Transaction Routing allows a local transaction to be shipped to a remote CICS region for processing, but there is no return to the originating CICS region.        5. TCP/IP sockets: TCP/IP sockets can be used in a client/server program relationship, with a complex send/receive protocol for each end of the communication channel and detailed error condition handling.        6. MQSeries: MQSeries can be used to send a request to a remote system via a message queue and receive a response message. MQSeries is designed to be asynchronous, so complex programming methods must be utilized to send a synchronous request and wait for a response.        7. Distributed Program Link (DPL): DPL allows a local CICS program to initiate a program on a remote CICS region. Data can be passed to the remote program and response data can be returned. The remote program has full access to all storage and databases on the remote CICS region and can pass information back to the originating program.All of the above options require a detailed understanding of the selected programming interface, and in most cases require a separate type of programming on each end of the communication connection.        
The DPL option provides the simplest method for a program to communicate with another program on a remote system. In DPL, the remote program has access to every resource, database, and storage area on that CICS region, as well as connecting to another CICS region through the same interface. However, in order to pass information between the local and remote programs, a common data area (also referred to as “commarea”) is used. This is typically a data structure with defined fields which different programs at both ends utilize.
In the DPL type implementation, the required components include a source program, a target program, and the data defining area (copybook or macro) used to pass information between the source program and the target program. The target program, for example, is unique because it responds to the source program, in order to obtain data from the remote system. However, in implementation, it is not possible to directly access the data on the remote system; it is only possible to access the files on the remote system. That is, it is not possible to access the storage area on the remote system, using the local source program. Access to the storage area on the remote system is only possible using the target program on the remote system. Additionally, the data defining area has to be created such that it includes all fields associated with the remote system and it must be synchronized between the source program and the target program. This being the case, when a field in the data defining area is changed, the target program must have a corresponding change and, if not, the data will be corrupted. Accordingly, in use, the implementation of the source program, target program, and data-defining area requires additional programming and careful attention to synchronization, amongst other things.
Accordingly, there exists a need in the art to overcome the deficiencies and limitations described hereinabove.